CommuniGate TCP Settings

  • Using Single-User Dial-up Software 
  • Using Direct Links and Internet Routers 
  • TCP Activity Restrictions 
  • Configuring the TCP Settings 
  • Receiving TCP Connections 
  • Several CommuniGate modules use TCP protocols - the CommuniGate SMTP and CommuniGate POP are the most important modules using TCP. This document describes how the CommuniGate Server software uses TCP links to connect to the Internet.

    The server computer can be connected to the Internet via various TCP connection links: a direct, permanent (24x7) Internet link can be available, a simple single-user PPP software (such as FreePPP or OT/PPP) can be used, or your server computer can have access to a dial-up TCP router installed on the server computer or the Server network.


    Using Single-User Dial-up Software

    When you use the OT/PPP or FreePPP "single user" software, you are not supposed to receive any incoming TCP connections with your CommuniGate Server (with one exception). Most likely, your server does not even have a static IP address that can be used to connect to the server. As a result, the CommuniGate Server can serve only AppleTalk-based client applications, such as the CommuniGator or Claris Emailer in the AppleTalk mode.

    If you want to server TCP/IP-based client applications (such as Eudora®), please read the Serving POP and IMAP Clients document.

    When using a single-user dial-up software, check that:

    POP Service Settings
    the TCP Channels option in Serving POP Clients field is set to zero.
    SMTP Service Settings
    the TCP Channels in the Receiving Options is set to zero.

    If you do use SMTP to receive incoming connections and to retrieve Internet mail (SMTP feeds), you should set the number of channels to non-zero, and you should not select the Always Keep Ready option: disabling this option tells the SMTP module to prepare for receiving only at the specified time intervals.
    IMAP Service Settings
    The TCP Channels option in the Serve IMAP Clients field is set to zero.
    PWD Service Settings
    The TCP Channels option in the Serve PWD Clients field is set to zero.
    UUCP Service Settings
    The Accept TCP Connections option is not selected.
    If you change any of these setting, the CommuniGate module will send so called "unconditional requests", keeping the TCP software ready for incoming connections. This will result in re-dialing and re-connecting to the Internet as soon as the link is dropped.

    If your Server is equipped with the FreePPP software, make sure you have configured the FreePPP software properly.

    If your Server is equipped with the OT/PPP (or ARA 3.0) software, make sure you have configured the OT/PPP software properly.


    Using Direct Links and Internet Routers

    When your network has a direct Internet link or it has a dial-up Internet Router installed, your CommuniGate Server can accept TCP connections from applications running on other computers on the local network. As a result, the CommuniGate Server (and communication modules) can serve TCP-based mailer applications. Read the Serving POP and IMAP Clients document for the details.

    If your Server is equipped with the Vicomsoft Internet Gateway software, make sure you have configured the Vicomsoft Gateway software properly.


    TCP Activity Restrictions

    When the Server computer employs a dial-up Internet link, it is important to restrict the System TCP/IP activity to keep the connection time as short as possible.

    All CommuniGate modules consult the CommuniGate Server kernel before they start any TCP activity. This method allows for centralized administrating of the CommuniGate System TCP activity.

    A module that wants to start a TCP session passes the priority value with the activity request. The CommuniGate Server may allow the module to start a high priority activity while rejecting regular-priority and the low-priority requests.

    If the CommuniGate Server rejects a request, the module displays the TCP/IP Link is Down message in the module status, and the module repeats an attempt later (usually, in 1 minute).

    If the CommuniGate Server has initiated a dial-up link, but a TCP/IP connection has not been established yet, the CommuniGate Server rejects a request, the module displays the Establishing a TCP/IP Link message, and the module repeats an attempt later (usually - in 10-25 seconds).

    See the CommuniGate Modules manuals for the details.

    If some of the POP accounts cannot be polled because a remote POP server is down, or if the SMTP module cannot access a "foreign mail server" because that server is not working, repeating attempts these module make may result in excessive phone costs for your dial-up system. To avoid this problem use the TCP Schedule settings to specify how often TCP connections can be initiated.

    If you have many users, then allowing the Server to start TCP activity immediately, as soon as any module sends a request, will cause the Server to initiate TCP links every time any user sends a message or when a user has a scheduled polling of an individual POP mailbox on a remote host. When the "how often" setting is set to 15 minutes, all submitted messages will stay in the SMTP queue, and dial-up links to the Internet will be established every 15 minutes. When a connection is established, all messages submitted by all users are sent, and all scheduled pollings of remote POP accounts are performed. If there is no message to send and no POP account to poll, the modules do not send requests to the Server, and the Server does not initiate dial-up links.


    Configuring the TCP Settings

    Choose General from the Server menu. The TCP Schedule Settings dialog box appears.
    Log:
    Use this setting to specify what kind of information the TCP Scheduler should put in the System Log. Usually you should use the Major (activity requests) or Problems (non-fatal errors) levels. But when you experience problems related to the TCP Activity restrictions, you may want to set the Log setting to Low-Level or All Info: in this case more low-level information about the TCP Scheduler activity will be recorded in the System Log, too. The TCP Schedule records in the System Log are marked with the TCP tag.
     
    Starting TCP Activity:
    You can create a TCP Schedule using the settings in this field. Each line specify the day (or days) of week, and the daytime interval. For each interval created the last setting specifies how often TCP/IP activity can be initiated.

    When a low- or regular- priority request is received, the Schedule is checked.

    The sample above allows the Server to initiate TCP Sessions every 5 minutes (if needed) during the working hours (6:00 a.m. - 6:00 p.m.) on weekdays, every hour afterhours (including the period from midnight to 6:00 a.m. on Monday and from 6:00 p.m. till midnight on Friday), and every 4 hours during weekends.

    A request to start TCP Activity is accepted if the TCP link is still active and that link was initiated less than 2 minutes ago. If a link is up for more than 2 minutes, every new request is accepted only if allowed with the TCP Schedule.

     
    Use High-Priority Sessions for Regular Communications
    When a module issues a high-priority request to start TCP/IP activity, the CommuniGate Server ignores the Schedule settings and tries to initiate the session. If that session is still in progress (the TCP/IP link is still established) when a regular-priority request arrives, the CommuniGate Server checks this option. If this option is selected, the regular-priority requests is accepted.
    For example, if a high-priority message is sent, the SMTP module sends a high-priority request to the CommuniGate Server. If the connection is established and this option is selected, then not only the high-priority message is sent to the Internet, but all regular-priority messages in the SMTP module queue are sent to the Internet, too.
     
    The CommuniGate Server detects if the server computer uses a dial-up TCP software. The recognized dial-up products include: When the CommuniGate Server recognizes a dial-up product, the Dialup Links options become available.
    Use Links Initiated by Others
    When this option is selected, the CommuniGate Server accepts all TCP activity requests if the dial-up link has been already established - either manually or with some other application running on the Server computer.
    For example, if the user starts an Internet application (as a Web browser) on the Server computer and it forces the dial-up software to establish a TCP link, the CommuniGate Server will allow all the communication modules to send and receive mail via the Internet while the user is browsing the Web - even if the TCP Schedule settings do not allow the Server to initiate TCP activity at that time.
     
    If fails to Link, Retry:
    If a dial-up TCP connection is not established when a module sends a request and the TCP Schedule settings allow the Server to accept that request, then the Server initiates the dialing process. The server controls the status of the dial-up software, and it returns the special Establishing a TCP Link code to the communication modules till the link is established. If the dial-up software fails to connect to the Internet and reports an error, the CommuniGate Server stops all attempts to initiate TCP Links. This option specifies when the Server is allowed to try to initiate TCP Links again.
     
    Check if the Serial Port is Busy:
    This option is effective for the FreePPP software only, and it should be selected if the Server computer does not have any serial port arbitration software installed.

    Receiving TCP Connections

    When some of your modules are configured to receive incoming TCP connections (if you use an Internet Router), these module send special "unconditional" requests to the Server. These requests are always satisfied (expect for the first 2 minutes of the Server activity), since these actions do not start any real TCP/IP activity - the modules just allocate the TCP resources required to accept incoming connections. When processing these requests, the Server ignores the TCP Schedule settings.